WAP (Wireless Application Protocol) Architecture
WAP (Wireless Application Protocol) is a standard proposed by the WAP Forum (http://www.wapforum.org) [Ref-1, Ref-5] that allows information to be sent and received by wireless devices. WAP has been deployed in several existing cellular wireless data networks (e.g., GSM, TDMA and CDMA).
WAP capable wireless devices (WAP devices) have several operational constraints compared to traditional Internet access devices such as personal computers. These limitations include a less powerful CPU, less memory, restricted power consumption, smaller display, and different input methods to the device. In addition, WAP devices operate in an environment that generally provides less bandwidth, less connection stability, less predictable availability, and greater latency than their wire-line counterparts. With these considerations, the WAP Forum introduced a new network element called the WAP Gateway that was targeted at addressing one or more of these issues.
In a traditional browser environment the processing and caching takes place in a single location with the display being located adjacent to the data handling. The WAP gateway splits this process acting as a proxy (i.e. hosting default home page, recording cookies, content and protocol conversions, etc.) for the devices as shown in FIG. 1A. In addition, the WAP gateway has been forced to provide several adjacent functions that assist in the end-to-end flow of data as part of the bridging or proxy function that they perform in the wireless network.
Another prior art concept is the unique identification of subscriber in the IP and wireless domains. However, due to privacy concerns, the WAP standard does not allow the device to send in a unique identifier in its requests, where one such identifier may be the phone number of the device, commonly referred as the MSISDN (Mobile Subscriber ISDN number). This inability to transmit an ID poses a serious challenge to the application development on the Web server which does not have a consistent means to identify the WAP device and hence the user. The solution, from application development side, is to require the user to log on by typing a user ID or MSISDN plus a password. Owing to the limited capability of the input method on the device, this is both inconvenient and difficult. Therefore, a need exists for a more convenient and simple way to allow WAP or wireless data requests to be tagged with IDs so that services can be differentiated on a request-by-request basis, a user-by-user basis, or a device-by-device basis, since this function is desirable and is not possible using conventional devices.
WAP gateway vendors have developed solutions to obtain IP address to MSISDN mapping from the NAS (Network Access Server) or AAA (Authentication, Authorization and Accounting) server. The WAP gateway then can identify each WAP request by the IP address and pass the MSISDN either in the URL or the HTTP header to applications running on Web servers. This requires the WAP gateway to collocate with the NAS or AAA in the carrier domain, which limits the configuration possibilities of the system. Enterprises and Wireless Portals who would like to control user experience by owning the WAP gateway will not have access to this critical information in the NAS or AAA, whereby flexibility within the system is lost when using this approach.
Another prior art method involves using the service control in existing WAP implementations. In existing wireless data networks the choice of WAP application is established through:                1. WAP page selection system; or        2. Multiple-profile system.        
In the WAP page selection system, the subscriber is presented multiple origin server choices through a single WAP gateway (WAP implementations/protocol associate a WAP device with a single WAP gateway).
The IP address of the WAP gateway is embedded in the WAP device restricting the device from accessing any other end-point directly and forcing one single WAP gateway to provide all services to the WAP device. This severely restricts the flexibility and scope of services that may be provided to the end user. In summary, this type of a system results in two major problems:                1. A security problem known as the WAP security hole; and        2. A service problem where the services that are provided to the subscriber are undifferentiated or inflexible.WAP Security Hole        
In a traditional WAP session a data request is encrypted by the WAP device and transmitted over the WAP device to the WAP gateway using the Wireless Transport Layer Security (WTLS) protocol [Ref-6]. The WAP gateway is then forced to decrypt the message and then re-encrypt it using another protocol (e.g. Secure Socket Layer) before transmitting it to the data content site origin server (FIG. 1B). The WTLS certificate only authenticates the WAP device to the WAP gateway. Therefore, to ensure end-to-end authentication, the WAP gateway would need to reside on the content site. However, the presence of an embedded WAP gateway IP address in the WAP device forces the subscriber to break connection with the network, re-program the IP address in the WAP device for each separate WAP service access. For mission-critical applications that demand high data security, it's desirable to have the WAP gateway co-located with the application. Therefore, a different manner of delivering encrypted WAP traffic is needed to ensure that the WAP security hole problem is solved or at least reduced in severity.
Undifferentiated Service
When subscribers access applications through a single WAP gateway, the network service level they receive is limited by the service tier of the WAP gateway (which is the primary network element). As a result, in centralized WAP gateway deployments, both critical and casual applications have the same bandwidth allocation, the same latency, and the same security parameters associated with them in a single service tier. In order for individual application bundles to be associated with differentiated service tiers a unique WAP gateway needs to be coupled with each bundle. The combination of the applications plus the network service level then creates a “WAP service level”.
In a conventional multiple-profile system, the subscriber defines multiple profiles with each profile containing a unique WAP gateway IP address, NAS (Network Access Server) dialup number, user ID and password. Unfortunately, switching to a new application, forces the subscriber to terminate the current session, modify the profile choice, and start a new session. Dynamically changing the WAP gateway provider within the same session is impossible using conventional techniques and systems. The process to create multiple profiles is cumbersome, tedious, and technically challenging. In addition, wireless network operators have no control over a user's selection on WAP gateway providers, and thus cannot guarantee overall service control. Therefore, a need exists for a system that allows a user to change WAP gateways dynamically while in session whereby such a process will also allow tighter and more dynamic control of the quality of service (QoS) on a session-by-session basis.
Wireless Data—Parameter Support
Wireless applications have enhanced usability when they are integrated with wireless-specific information. This includes support for features such as roaming and market preferences such as pre-paid and pay-per-use support.
Roaming
WAP roaming is currently achieved with one of the following methods.
                User making long distance calls to the home networks that incurs a huge cost to the user, and is therefore unpopular.        Upgrading the NAS/RAS server in the roaming network to tunnel back to the home network, which is complex and inflexible.        Using a foreign WAP gateway to access the home WAP portals without accessing back to the home network. This methodology loses the user identity at the home WAP system and substantially discounts the user experience.        Using a local dial-up ISP to access the WAP gateway in the home network. Again the user identity will be lost in this approach.        
All the existing approaches to roaming are either cost inefficient, unnecessarily complex, and/or substantially reduce the user experience. In addition the prior art does not recognize or provide the ability to provide local services selectively when in a roamed network, largely due to the fact that, in most cases, the user identity is lost.
Pre-Paid and Pay-per-use Support for Wireless Data Services
Mobile Network Operators (MNOs) and Service Providers have developed various pre-paid service packages where services are only provided when there are credits in subscribers' pre-purchased accounts. Pre-paid services have become extensively used by subscribers. However, the pre-paid packages are limited to voice services only and currently there are no pre-paid data services available on conventional networks. This is often due to the fact that the system cannot always identify the user and offer the user unique or selective packages. In addition, the single gateway through which the user accesses the data is only capable of processing certain packages that by definition will limit certain services offered to the subscriber.
Another concept which is yet to be developed in the wireless data network is the pay-per-use data service. In this scenario, subscribers may or may not sign up with the MNO, but can purchase service as they go, on the basis of usage time or number of accesses. Again, this has not been possible in conventional system due to limitations in the configuration and operation of the system.
The current art would restrict or prevent pay-per-use and pre-paid selections to be applied by all applications within a single gateway, thus eliminating the possibility of selective pre-paid application use on a user-by-user or session-by-session basis.